Criando vários sites WordPress localmente com o DevKinsta

Este artigo foi gentilmente apoiado por nossos queridos amigos da DevKinsta, que ajudam muitos desenvolvedores, web designers e freelancers a projetar, desenvolver e implantar seus sites WordPress de todo o mundo. Obrigado!

Ao criar temas e plugins para WordPress, precisamos garantir que funcionem bem em todos os diferentes ambientes em que serão instalados. Às vezes, podemos controlar esse ambiente ao criar um tema para nossos próprios sites, mas outras vezes não podemos, como quando distribuímos nossos plugins por meio do repositório público do WordPress para qualquer pessoa fazer o download e instalá-lo.

Em relação ao WordPress, as possíveis combinações de ambientes para nos preocuparmos incluem:

• Diferentes versões do PHP,
• Diferentes versões do WordPress,
• Diferentes versões do editor do WordPress (também conhecido como editor de blocos),
• HTTPS ativado/desativado,
• Multisite ativado/desativado.

Vamos ver como este é o caso. O PHP 8.0, que é a versão mais recente do PHP, introduziu mudanças importantes em relação às versões anteriores. Como o WordPress ainda suporta oficialmente PHP 5.6, nosso plugin pode precisar suportar 7 versões do PHP: PHP 5.6, além de PHP 7.0 a 7.4, além de PHP 8.0. Se o plug-in exigir algum recurso específico do PHP, como propriedades tipadas (introduzidas no PHP 7.4), ele precisará suportar essa versão do PHP em diante (neste caso, PHP 7.4 e PHP 8.0).

No que diz respeito ao versionamento no WordPress, este software em si pode ocasionalmente introduzir alterações importantes, como a atualização para uma versão mais recente do jQuery no WordPress 5.6. Além disso, cada versão principal do WordPress apresenta novos recursos (como o novo editor Gutenberg, introduzido na versão 5.0), que podem ser necessários para nossos produtos.

O editor de blocos não é exceção. Se nossos temas e plugins contiverem blocos personalizados, é imperativo testá-los para todas as versões diferentes. No mínimo, precisamos nos preocupar com duas versões do Gutenberg: a enviada no núcleo do WordPress e a disponível como um plugin autônomo.

Tanto no que diz respeito ao HTTPS quanto ao multisite, nossos temas e plugins podem se comportar de maneira diferente dependendo de estarem ativados ou não. Por exemplo, podemos querer desabilitar o acesso a um endpoint REST quando não estiver usando HTTPS ou fornecer recursos estendidos ao superadministrador do multisite.

Isso significa que há muitos ambientes possíveis com os quais precisamos nos preocupar. Como lidamos com isso?

Descobrindo os ambientes

Tudo o que pode ser automatizado, deve ser automatizado. Por exemplo, para testar a lógica de nossos temas e plugins, podemos criar um processo de integração contínua que executa um conjunto de testes em vários ambientes. A automação elimina uma grande parte da dor.

No entanto, não podemos confiar apenas em que as máquinas façam todo o trabalho para nós. Também precisaremos acessar algum site WordPress de teste para visualizar se, após alguma atualização de software, nossos temas ainda parecem como pretendidos. Por exemplo, se o Gutenberg atualizar seu sistema de estilos globais ou como um bloco principal se comporta, queremos verificar se nossos produtos não foram afetados pela mudança.

Quantos ambientes diferentes precisamos suportar? Digamos que estamos visando 4 versões do PHP (7.2 a 8.0), 5 versões do WordPress (5.3 a 5.7), 2 versões do Gutenberg (core/plugin), HTTPS ativado/desativado e multisite on/off. Tudo equivale a um total de 160 ambientes possíveis. Isso é demais para lidar.

Para simplificar as coisas, em vez de produzir um site para cada combinação possível, podemos reduzi-lo a um punhado de ambientes que, em geral, abrangem todas as diferentes propriedades.

Por exemplo, podemos produzir esses cinco ambientes:

1. PHP 7.2 + WP 5.3 + núcleo Gutenberg + HTTPS + multisite
2. PHP 7.3 + WP 5.4 + plugin Gutenberg + HTTPS + multisite
3. PHP 7.4 + WP 5.5 + plugin Gutenberg + sem HTTPS + sem multisite
4. PHP 8.0 + WP 5.6 + núcleo Gutenberg + HTTPS + sem multisite
5. PHP 8.0 + WP 5.7 + núcleo Gutenberg + sem HTTPS + sem multisite

Criar 5 sites WordPress é gerenciável, mas não é fácil, pois envolve desafios técnicos, principalmente habilitar diferentes versões do PHP e fornecer certificados HTTPS.

Queremos criar sites WordPress com facilidade, mesmo que tenhamos conhecimento limitado de sistemas. E queremos fazê-lo rapidamente, pois temos nosso trabalho de desenvolvimento e design a fazer. Como podemos fazer isso?

Gerenciando sites locais do WordPress com o DevKinsta

Felizmente, criar sites locais do WordPress não é difícil hoje em dia, pois podemos evitar o trabalho manual e, em vez disso, contar com uma ferramenta que automatiza o processo para nós.

DevKinsta é exatamente esse tipo de ferramenta. Ele permite lançar um site local do WordPress com o mínimo esforço, para qualquer configuração desejada. O site será criado em menos tempo que leva para beber uma xícara de café. E certamente custa menos que uma xícara de café: o DevKinsta é 100% gratuito e está disponível para usuários de Windows, macOS e Ubuntu .

Como o próprio nome sugere, o DevKinsta foi criado pela Kinsta, um dos principais provedores de hospedagem no espaço WordPress. Seu objetivo é simplificar o processo de trabalho com projetos WordPress, seja para designers ou desenvolvedores, freelancers ou agências. Quanto mais fácil pudermos configurar nosso ambiente, quanto mais pudermos nos concentrar em nossos próprios temas e plugins, melhores serão nossos produtos.

A mágica que impulsiona o DevKinsta é o Docker, o software que permite isolar um aplicativo de seu ambiente por meio de contêineres. No entanto, não somos obrigados a conhecer o Docker ou os contêineres: o DevKinsta oculta a complexidade subjacente, para que possamos iniciar o site WordPress com o pressionar de um botão.

Neste artigo, exploraremos como usar o DevKinsta para iniciar as 5 instâncias locais diferentes do WordPress para testar um plug-in e quais recursos interessantes temos à nossa disposição.

Lançando um site WordPress com DevKinsta

As imagens acima mostram o DevKinsta ao abri-lo pela primeira vez. Apresenta 3 opções para criar um novo site WordPress local:

1. Novo site WordPress
   Ele usa a configuração padrão, incluindo a versão mais recente do WordPress e o PHP 8.
2. Importar da Kinsta
   Ele clona a configuração de um site existente hospedado no MyKinsta.
3. Site personalizado
   Ele usa uma configuração personalizada, fornecida por você.

Pressionar a opção nº 1 produzirá literalmente um site WordPress local sem nem pensar nisso. Eu poderia explicar um pouco mais se pudesse; não há realmente mais do que isso.

Se você for um usuário Kinsta, pressionar a opção #2 permite importar diretamente um site do MyKinsta, incluindo um dump de seu banco de dados. (A propósito, também funciona na direção oposta: alterações locais no DevKinsta podem ser enviadas para um site de teste no MyKinsta.)

Por fim, ao pressionar a opção #3, podemos especificar qual configuração personalizada usar para o site local do WordPress.

Vamos pressionar o botão para a opção #3. A tela de configuração ficará assim:

Algumas entradas são somente leitura. Estas são opções que estão atualmente corrigidas, mas serão configuradas em algum momento no futuro. Por exemplo, o servidor web está atualmente configurado para Nginx, mas o trabalho para adicionar o Apache está em andamento.

As opções que podemos configurar atualmente são as seguintes:

• O nome do site (a partir do qual o URL local é calculado),
• Versão do PHP,
• Nome do banco de dados,
• HTTPS ativado/desativado,
• O título do site WordPress,
• Versão do WordPress,
• O e-mail, nome de usuário e senha do administrador,
• Multisite ativado/desativado.

Depois de preencher essas informações para o meu primeiro site WordPress local, chamado “GraphQL API on PHP 80”, e clicar em “Criar site”, bastou para o DevKinsta criar o site em apenas 2 minutos. Em seguida, é apresentada a tela de informações do site recém-criado:

O novo site WordPress está disponível em seu próprio domínio local graphql-api-on-php80.local . Clicando no botão “Abrir site”, podemos visualizar nosso novo site no navegador:

Repeti esse processo para todos os diferentes ambientes necessários e voila, meus 5 sites locais do WordPress estavam funcionando rapidamente. Agora, a tela inicial do DevKinsta lista todos os meus sites:

Usando WP-CLI

Da configuração necessária para meus ambientes, até agora satisfiz todos os itens, exceto um: instalar o Gutenberg como um plug-in.

Vamos fazer isso a seguir. Podemos instalar um plugin o usual através do WP admin, que podemos acessar clicando no botão “WP admin” na tela de informações do site, como visto na imagem acima.

Melhor ainda, o DevKinsta vem com o WP-CLI já instalado, para que possamos interagir com o site WordPress através da interface de linha de comando.

Nesse caso, precisamos ter um conhecimento mínimo do Docker. A execução de um comando dentro de um container é feita assim:

 docker exec {containerName} /bin/bash -c '{command}'

Os parâmetros necessários são:

• O contêiner do DevKinsta é chamado devkinsta_fpm .
• O comando WP-CLI para instalar e ativar um plugin é wp plugin install {pluginName} --activate --path={pathToSite} --allow-root
• O caminho para o site WordPress, dentro do contêiner, é /www/kinsta/public/{siteName} .

Juntando tudo, o comando para instalar e ativar o plugin Gutenberg no site local do WordPress é este:

 docker exec devkinsta_fpm /bin/bash -c 'wp plugin install gutenberg --activate --path=/www/kinsta/public/MyLocalSite --allow-root'

Explorando recursos

Existem alguns recursos úteis disponíveis para nossos sites locais do WordPress.

A primeira é a integração com Adminer, uma ferramenta semelhante ao phpMyAdmin, para gerenciar o banco de dados. Com esta ferramenta, podemos buscar e editar os dados diretamente por meio de uma consulta SQL personalizada. Clicar no botão “Gerenciador de banco de dados”, na tela de informações do site, abrirá o Adminer em uma nova aba do navegador:

O segundo recurso digno de nota é a integração com o Mailhog, a popular ferramenta de teste de e-mail. Graças a esta ferramenta, qualquer e-mail enviado do site WordPress local não é realmente enviado, mas é capturado e exibido na caixa de entrada de e-mail:

Clicando em um e-mail, podemos ver seu conteúdo:

Acessando os arquivos de instalação locais

Depois de instalar o site local do WordPress, sua pasta contendo todos os seus arquivos (incluindo o núcleo do WordPress, temas e plugins instalados e itens de mídia carregados) estará disponível publicamente:

• Mac e Linux: em /Users/{username}/DevKinsta/public/{siteName} .
• Windows: em C:\Users\{username}\DevKinsta\public\{siteName} .

(Em outras palavras: os arquivos do site WordPress local podem ser acessados ​​não apenas pelo contêiner do Docker, mas também pelo sistema de arquivos em nosso sistema operacional, como usando My PC no Windows, Finder no Mac ou qualquer terminal.)

Isso é muito conveniente, pois oferece um atalho para instalar os temas e plugins que estamos desenvolvendo, agilizando nosso trabalho.

Por exemplo, para testar uma mudança em um plugin em todos os 5 sites locais, normalmente teríamos que ir ao administrador do WP em cada site e fazer o upload da nova versão do plugin (ou, alternativamente, usar o WP-CLI).

Ao ter acesso à pasta do site, porém, podemos simplesmente clonar o plugin de seu repositório, diretamente em wp-content/plugins :

 $ cd ~/DevKinsta/public/MyLocalSite/wp-content/plugins $ git clone [email protected]:leoloso/MyAwesomePlugin.git

Dessa forma, podemos apenas git pull para atualizar nosso plugin para sua versão mais recente, tornando-o imediatamente disponível no site local do WordPress:

 $ cd MyAwesomePlugin $ git pull

Se quisermos testar o plugin em desenvolvimento em um branch diferente, podemos fazer um git checkout :

 git checkout some-branch-with-new-feature

Como podemos ter vários sites com ambientes diferentes, podemos automatizar esse procedimento executando um script bash, que itera os sites locais do WordPress e, para cada um, executa um git pull para o plugin instalado em:

 #!/bin/bash iterateSitesAndGitPullPlugin(){ cd ~/DevKinsta/public/ for file in * do if [ -d "$file" ]; then cd ~/DevKinsta/public/$file/wp-content/plugins/MyAwesomePlugin git pull fi done } iterateSitesAndGitPullPlugin

Conclusão

Ao projetar e desenvolver nossos temas e plugins do WordPress, queremos poder nos concentrar em nosso trabalho real, tanto quanto possível. Se pudermos automatizar a configuração do ambiente de trabalho, poderemos investir tempo e energia extras em nosso produto.

Isso é o que o DevKinsta torna possível. Podemos criar um site WordPress local apenas pressionando um botão e criar muitos sites com ambientes diferentes em apenas alguns minutos.

O DevKinsta está sendo desenvolvido e suportado ativamente. Se você tiver algum problema ou tiver alguma dúvida, poderá navegar pela documentação ou acessar o fórum da comunidade, onde os criadores do DevKinsta o ajudarão.

Tudo isso, de graça. Parece bom? Nesse caso, baixe o DevKinsta e gire seus sites locais do WordPress.