Como abordar o desenvolvimento moderno do WordPress (Parte 1)

Publicados: 2022-03-11

Não é nenhum segredo que a base de código do WordPress é uma bagunça. Pessoalmente, toda vez que passo por isso, tudo o que quero é me enrolar e chorar. Por outro lado, o WordPress está muito à frente de sua concorrência. Um CMS poderoso e fácil de usar é um empreendimento enorme, e o WordPress continua popular porque oferece isso.

Então, por que nos preocupamos com a qualidade do código no núcleo do WordPress? Funciona, certo?

Sim, funciona, e é improvável que a base de código de 15 anos seja completamente refatorada por seus mantenedores voluntários. Infelizmente, isso significa que também funciona como um exemplo de codificação “à maneira do WordPress”, desculpando vários desenvolvedores por não seguirem as melhores práticas e técnicas modernas de desenvolvimento. Tantos plugins e temas do WordPress têm código infamemente ruim, e seguir cegamente as práticas herdadas apenas continua a tendência.

Mas quem se importa com código ruim que ainda faz seu trabalho? Bem, nada é de graça, e alguém paga por um trabalho mal feito. Com a própria base de código do WordPress, seus mantenedores pagam com seu tempo, felizmente. Mas com o seu próprio código, é o seu cliente que paga.

Para qualquer sistema, mesmo moderadamente complexo, o custo do desenvolvimento inicial é insignificante comparado ao custo de manutenção, e a manutenção também significa adicionar novas funcionalidades. Contratar um desenvolvedor para consertar um software mal projetado e implementado vai custar várias vezes mais do que desenvolvê-lo adequadamente desde o início.

Soluções baratas são sempre as mais caras a longo prazo. Ou eles são abandonados depois de ficar sem orçamento. Na verdade, economizamos o dinheiro dos clientes quando seguimos princípios e práticas comprovados de design de software. Esses métodos não são uma moda passageira, nem mudam por causa da mudança. A sabedoria aqui nasce da experiência coletiva do desenvolvedor, e segui-la realmente vale a pena.

Obviamente, isso não se aplica a tarefas realmente simples, como adicionar algumas linhas de CSS ou algumas postagens personalizadas e reescrever. Mas juntar alguns plugins (ou mais comumente várias dezenas de plugins) ou produzir um site com o Visual Composer não é engenharia de software, de qualquer maneira.

Isso não é uma coisa ruim, por si só - o fato de algumas soluções serem tão simples é o motivo pelo qual o WordPress é tão popular. Mas nesta série vou falar sobre o desenvolvimento real do WordPress: escrever código PHP, HTML, CSS e JavaScript significativo. Vou começar com o fluxo de trabalho geral e, em seguida, focar no desenvolvimento front-end do WordPress neste artigo.

Fluxo de trabalho de desenvolvimento moderno do WordPress

Em geral, o código de qualidade é:

  • Legível. É fácil entender o que o código faz e por quê.
  • Modular. Pequenos blocos de código com um propósito claro são fáceis de entender, desenvolver e testar.
  • Reutilizável. A reutilização de módulos já desenvolvidos para resolver problemas semelhantes acelera significativamente o desenvolvimento.
  • Sustentável. Modificar funcionalidades antigas ou introduzir novos recursos é fácil.

Os principais resultados—menor custo de desenvolvimento e propriedade—têm muitos benefícios derivados dos quais não entrarei aqui.

Em vez disso, vou me concentrar em quais técnicas de desenvolvimento e práticas recomendadas podem ajudá-lo a produzir código de qualidade. Vamos começar com o controle de versão.

Usar controle de versão

Isso significa usar o Git. Infelizmente, a “codificação de cowboy” na produção por FTP ainda é uma coisa. Recentemente, trabalhei para uma agência sediada no Reino Unido e eles tinham arquivos com nomes como esses em toda a base de código:

  • functions copy.php
  • functions copy 2.php
  • functions test.php
  • functions2.php
  • functions test2.php

A primeira coisa que você deve fazer ao criar um site WordPress é colocá-lo sob controle de versão. Tanking Servers é uma divertida retrospectiva dos erros de desenvolvimento do WordPress. Teria sido muito fácil corrigir esses - e contratempos semelhantes que provavelmente aconteceram com todos - usando o Git.

Cometeu um erro no seu código e todo o site caiu? git reset recupera tudo do jeito que estava. Nova atualização de versão quebrou tudo? git reset funciona como uma máquina do tempo. Algum código malicioso apareceu do nada? git status mostra todos os novos arquivos, arquivos excluídos ou alterações em qualquer arquivo rastreado. Depois é só fazer o git checkout , restaurando os originais.

Cuidado ao expor a pasta .git

OK, é claramente importante usar o Git. Mas quando você faz isso, é tão importante evitar expor seu repositório Git a ser hackeado. O problema surge quando você tem pastas .git expostas e armazena suas credenciais nelas.

Uma instalação padrão do WordPress fica totalmente em uma pasta da web pública, e é muito provável que a pasta .git também esteja lá. Obviamente, nenhuma credencial de login deve ser armazenada no repositório Git, mas acontece que a maioria dos repositórios contém algumas informações confidenciais que não devem ser vazadas para fora.

Portanto, o acesso público à pasta .git deve ser bloqueado. Se você estiver usando o Apache, adicionar o snippet abaixo na parte superior do arquivo .htaccess bloqueará o acesso à pasta .git e também aos arquivos de log. Os arquivos de log geralmente contêm informações confidenciais, portanto, é aconselhável torná-los indisponíveis também. Para diferentes configurações de servidor web, peça ajuda ao seu especialista em DevOps.

 RedirectMatch 404 /\.git RedirectMatch 404 ^.*\.log

Use ambientes separados

Não faça desenvolvimento em sites ativos - esta é uma receita para tempo de inatividade e clientes insatisfeitos. OK, mas como você deve configurá-lo?

Idealmente, deve haver três ambientes de desenvolvimento, com o código sempre indo em uma direção: local → preparação → produção. Este é um método comprovado para evitar colisões. Todas as atualizações de núcleo, plugin e tema são feitas primeiro localmente, depois testadas na preparação e, finalmente, implantadas na produção.

Por exemplo, a configuração específica do servidor pode ser armazenada em um arquivo separado. Você pode criar um wp-config-local.php para cada ambiente local e de teste. (Não se esqueça de adicioná-lo ao seu arquivo .gitignore !) Em seguida, adicione o seguinte trecho ao wp-config.php :

 if (file_exists(dirname(__FILE__) . '/wp-config-local.php')) : // use local settings require_once(dirname(__FILE__) . '/wp-config-local.php'); else : // production settings endif;

Muitas vezes, a melhor maneira de configurar ambientes diferentes é usar variáveis ​​de ambiente. Se você não estiver familiarizado com esse conceito, aconselho usar uma solução moderna completa como o Roots.

Usar WP-CLI

A interface de linha de comando do WordPress (WP-CLI) é uma ferramenta extremamente útil para administrar instalações do WordPress. Ter acesso ao WP-CLI significa ter a capacidade de executar praticamente qualquer função da API do WordPress. Por exemplo, você pode adicionar, remover e editar usuários e suas senhas com WP-CLI. Útil se você acabou de herdar um site e o proprietário se bloqueou.

Outro exemplo é que a implantação inicial é muito fácil com o WP-CLI. Isso pode ser feito com alguns comandos:

  • Baixando núcleo, temas e plugins
  • Pesquisando e substituindo no banco de dados
  • Adicionando um usuário administrador

Além disso, essas ações podem ser roteirizadas e automatizadas.

Usar opções avançadas de implantação

Falando em automação, vale a pena aprender algumas tecnologias e processos de implantação como:

  • Integração contínua/implantação/entrega contínuas (CI/CD)
  • Janela de encaixe
  • Testes automatizados (incluindo testes de regressão front-end)

É verdade que passar de não usar o controle de versão para lidar com o Docker é um grande salto a ser dado e provavelmente será esmagador para um projeto WordPress típico de uma pessoa. Algumas opções podem nem ser possíveis dependendo do seu provedor de hospedagem. Mas a implantação avançada é obrigatória para equipes e projetos maiores.

Usar linting

Para projetos de qualquer tamanho, porém, o linting é uma benção para a maioria dos desenvolvedores. Linting significa verificar automaticamente se há erros no seu código. Um IDE completo, como PHPStorm, já faz isso pronto para uso; no entanto, editores mais simples, como VSCode ou Sublime Text, precisam de um programa dedicado chamado linter. Uma maneira de configurar isso é configurar seu editor para executar um linter sempre que você salvar um arquivo.

PHP_CodeSniffer é o linter de fato para PHP. Além de verificar erros de sintaxe, ele também pode verificar se seu código segue diretrizes de estilo, como PSR-2. Isso simplifica bastante os seguintes padrões de codificação.

Para JavaScript, ESLint é um linter popular. Ele possui um extenso conjunto de regras e suporta configurações personalizadas para todos os tipos e estruturas de JavaScript existentes.

Um caso de uso poderoso aqui é incorporar linting em um pipeline de compilação de CI/CD para que todo o código seja validado automaticamente antes de ser implantado.

Técnicas modernas de desenvolvimento de front-end do WordPress

Com um fluxo de trabalho adequado agora configurado para seu projeto geral do WordPress, vamos mergulhar nas melhores práticas para o front-end.

Use ferramentas modernas: Sass e ES6+

O mundo do desenvolvimento front-end está em constante mudança e sempre em movimento. Uma vez que pensamos que o Sass era a melhor ferramenta para escrever CSS – e para o desenvolvimento WordPress pré-Gutenberg, ainda é – mas então todos começaram a falar sobre CSS-in-JS e componentes estilizados.

Mesmo o WordPress não resistiu e pegou algumas dessas novas tecnologias. Gutenberg, o novo editor de blocos, é construído em React e uma API REST.

Você definitivamente deve se atualizar com essas tecnologias principais de front-end:

  • ES6+. A documentação do WordPress o chama de ESNext e até incentiva o uso.
  • Sass. Usado pelo WooCommerce e a melhor maneira de escrever CSS se você ainda não gosta do CSS-in-JS.
  • Webpack. Até o núcleo do WordPress usa Webpack e Babel agora.

ES6 e Sass são JavaScript e CSS modernos, respectivamente, e o Webpack é uma ferramenta que permite usar todos esses recursos modernos sem se preocupar com compatibilidade com versões anteriores. O Webpack pode ser chamado de compilador de aplicativos front-end que gera arquivos para uso em um navegador.

Transição de jQuery para Vue.js ou React

O núcleo do WordPress e quase todos os plugins do WordPress dependem do jQuery, então você não pode simplesmente parar de usá-lo. Na verdade, não faz sentido parar de usá-lo para tarefas simples, como ocultar alguns <div> s ou fazer uma solicitação AJAX única quando você está acostumado a fazê-lo dessa maneira. jQuery será carregado de qualquer maneira, e é simples e fácil de usar.

Aplicativos complexos são onde o jQuery luta: lógica difícil de seguir, inferno de retorno de chamada, variáveis ​​globais e nenhum modelo HTML. Isso claramente exige uma maneira diferente de organizar o aplicativo front-end.

Bibliotecas front-end modernas, como React, usam princípios de programação orientada a objetos (OOP) e organizam a arquitetura de aplicativos front-end em componentes modulares e reutilizáveis. Um componente contém todo o código, marcação e “estado do componente” (variáveis) para um determinado elemento. Um elemento pode ser quase qualquer coisa: um botão, campo de entrada, formulário de usuário ou um widget que exibe postagens recentes do back-end da API REST do WordPress. Os componentes podem conter outros componentes, formando um relacionamento hierárquico.

Com a complexidade das páginas da Web hoje em dia, organizar um aplicativo em componentes é uma maneira comprovada de criar aplicativos da Web rápidos e de manutenção de qualquer complexidade. Os componentes são "tijolos" altamente reutilizáveis, isolados e, portanto, facilmente testáveis, por isso vale a pena aprender esse conceito.

Existem duas bibliotecas baseadas em componentes que estão em alta no momento: Vue.js e React. React seria uma escolha óbvia porque já é usado por Gutenberg. No entanto, para alguém novo no JavaScript moderno, o Vue.js pode ser melhor para começar.

O React leva você ao fundo do poço usando recursos do ES6, classes, sintaxe JSX proprietária e pipeline de compilação do Webpack imediatamente. A curva de aprendizado é bastante íngreme.

O Vue.js, por outro lado, é muito mais amigável para iniciantes e pode ser usado simplesmente colocando uma tag <script> . Vue.js usa JavaScript simples (ES5), HTML e CSS. A introdução a novos conceitos é muito mais gradual.

Depois de trabalhar em alguns projetos Vue.js, você estará melhor preparado para mergulhar profundamente no React. Não que seja sempre necessário, mas o desenvolvimento do Gutenberg, por exemplo, exige.

Use a API REST do WordPress

A API REST do WordPress é apenas uma interface padronizada para solicitar e modificar dados remotamente do WordPress. É mais uma coisa de arquitetura de software do que uma maneira completamente diferente de codificação. Os mesmos trechos de jQuery AJAX antigos podem ser usados ​​com parâmetros ligeiramente diferentes.

O benefício mais importante? Como a API REST do WordPress padroniza a comunicação entre o back-end e o front-end, é um passo importante em direção à modularidade, reutilização e legibilidade em seu código. Esses templates terríveis com HTML e PHP misturados e um pouco de SQL jogado na mistura têm que desaparecer. Uma vez que os modelos são apenas HTML com espaços reservados para dados passados ​​como parâmetros, não há grande diferença entre passar esses dados em PHP ou por meio de uma API REST para um aplicativo front-end.

Você também pode querer olhar para WPGraphQL. Pode ou não substituir a API REST do WordPress, mas está ganhando força rapidamente.

Aprenda Gutenberg (os clientes exigirão em breve)

O objetivo final do Gutenberg é a personalização completa do site, entre outros planos.

Isso estabelece as bases para um novo modelo para o WordPress Core que acabará por impactar toda a experiência de publicação da plataforma.

A página do projeto WordPress Gutenberg no GitHub

Gutenberg recebeu uma grande reação dos desenvolvedores do WordPress. Alguns dos argumentos contra a fusão no núcleo do WordPress foram:

  • Uma parcela significativa dos usuários finais não precisa dele, por isso deve ser um plug-in opcional e não parte do núcleo
  • quebrou alguns sites
  • Simplesmente não estava pronto e poderia usar mais polimento e menos bugs

No entanto, para escritores de conteúdo que usam o WordPress como plataforma de blog, o Gutenberg claramente oferece uma experiência melhor do que o antigo editor.

A desativação do Gutenberg será suportada enquanto for necessário, sim. Mas facilitar agora é uma ideia sábia: quando um cliente se aproximar de você e pedir para fazer o desenvolvimento do Gutenberg, você estará pronto.

Hora de acelerar: até o “jeito WordPress” está evoluindo

O argumento mais comum contra o uso de todas as ferramentas e técnicas descritas acima no desenvolvimento do WordPress é o seguinte: A “maneira WordPress” de fazer as coisas ainda funciona, e essa forma deve ser melhor do que todas essas coisas novas e brilhantes.

Mas agora você viu que os desenvolvedores principais do WordPress estão bem cientes de todos os desenvolvimentos mais recentes. Além disso, eles os usam o máximo possível em partes mais recentes do núcleo por causa de suas vantagens óbvias. A única coisa que nos impede é o código legado que ninguém vai refatorar.

Há algum tempo, WordPress e WooCommerce seguem a prática de desenvolver “plugins de recursos” que implementam e usam novas tecnologias. Quando for a hora certa, esses plugins serão mesclados no núcleo, como fez Gutenberg. O WooCommerce também tem seu próprio projeto React. A API REST do WordPress também começou como um plugin separado e agora faz parte do núcleo do WordPress.

A questão não é se devemos aprender coisas novas e usá-las no meu trabalho diário, mas como . A resposta é “gradualmente”, um passo de cada vez. Ou aprenda uma coisa nova ou faça algo que você conhece bem de uma maneira nova e diferente.

Por exemplo, aprenda como usar o Webpack com todos os seus scripts antigos. O Webpack pode transpilar seu novo código ES6+ para JavaScript “simples” compatível com navegadores mais antigos. Ele também pode minimizar scripts e agrupá-los. Isso é uma coisa nova. Feito? Em seguida, reescreva seu JavaScript aproveitando os recursos do ES6. É uma nova maneira de fazer o que você conhece bem.

O resultado: você aprenderá Webpack e ES6. Como profissionais, devemos intensificar e não recuar. Continue sempre aprendendo. E compartilhe quando você fizer isso: a Toptal mantém uma lista das melhores práticas de desenvolvimento do WordPress e agradece as contribuições da comunidade para ela.

Na Parte 2 de nossa série, vamos mergulhar na parte PHP do desenvolvimento de back-end moderno do WordPress.