Fluxo de trabalho de desenvolvimento moderno do WordPress com a pilha de raízes

O WordPress existe há muito tempo, pelo menos pelos padrões da Internet, e sua filosofia sempre foi preservar a compatibilidade com versões anteriores. Esse foco na compatibilidade é compreensível, dada a grande quantidade de sites WordPress online hoje. No entanto, embora isso possa ajudar aqueles que ainda usam ambientes legados com versões antigas de PHP e MySQL (o que é um risco de segurança em si, mas esse não é o tópico do artigo de hoje), também fez com que as versões mais recentes do WordPress não fizessem uso total os recursos PHP mais recentes.

Isso também fez com que muitos desenvolvedores do WordPress vivessem em uma bolha do WordPress, não sendo incentivados a aprender novas e modernas tecnologias de desenvolvimento front-end e, às vezes, ficarem presos no “bom e velho jeito” de fazer as coisas.

Você pode adotar um fluxo de trabalho de desenvolvimento moderno para WordPress?

Você certamente pode, e a pilha WordPress Roots está aqui para ajudá-lo a desenvolver como se fosse 2019, com três ferramentas incríveis:

• Sage como seu tema inicial,
• Bedrock como um clichê moderno do WordPress,
• Trellis para gerenciar a implantação e o provisionamento em diferentes ambientes.

A equipe Roots também tem duas ferramentas adicionais em desenvolvimento: Acorn, um framework de construção de plugins, e Clover, um clichê de plugins. Devido ao fato de ambos estarem em alfa, eles não estão incluídos neste artigo, mas você definitivamente deve ficar de olho neles.

O que exatamente é a pilha de raízes

Originalmente conhecido como o tema Roots, era um tema inicial HTML5 sólido, destinado a fornecer um ponto de partida mais limpo para novos sites WordPress. Com o tempo, evoluiu para um conjunto completo de ferramentas, passando por todas as principais tecnologias e padrões modernos da web (de Grunt a Gulp e Webpack, LESS e SCSS, NPM e Yarn, Bootstrap, padrões de codificação PSR-2 e o princípio DRY), forçando assim os desenvolvedores do WordPress que o adotaram a aprender continuamente e manter-se atualizados com o que as modernas tecnologias de desenvolvimento front-end têm a oferecer.

Hoje, o Roots se transformou em um conjunto completo de ferramentas em expansão contínua, com o objetivo de ajudá-lo a criar melhores sites WordPress seguindo todo o ciclo, desde o desenvolvimento até a preparação e a produção, e tornando você um desenvolvedor melhor, forçando-o a sair do conforto zona fornecida pela chamada bolha do WordPress.

Mas vamos dar uma olhada nas três principais ferramentas que eles oferecem, o que são e por que você deve considerar usá-los.

Raízes Sábio 9

O Roots Sage 9 é a última iteração de um tema inicial do WordPress mantido profissionalmente, originalmente lançado apenas como Roots em 2011. Durante sua vida, ele passou por muitas mudanças, melhorias e reconsiderações de práticas recomendadas, para finalmente se tornar o que hoje é um ótimo ponto de partida para apresentar o fluxo de trabalho de desenvolvimento de front-end moderno para o desenvolvimento do WordPress.

O que o Sage está tentando fazer é adotar um padrão MVC (Model-View-Controller) onde Views e Controller são completamente separados; isso nos permite reutilizar Views, que não precisam necessariamente “saber” de onde os dados estão vindo, mas eles simplesmente esperam que um Controller os alimente com alguns dados para serem exibidos.

O controlador incluído no Sage 9 não é o controlador real com o qual você já deve estar familiarizado em outros frameworks como o Laravel, a principal diferença é que o Sage 9 Controller usa um roteamento baseado em modelo em vez de um roteamento baseado em URL. Basicamente, você deixa o WordPress lidar com o roteamento de URL e escreve controladores para arquivos de modelo.

Ao adicionar alguns graus de complexidade a todo o processo de desenvolvimento, o Sage 9 pode não ser a melhor escolha para iniciantes, pois você terá um pouco de aprendizado para dominá-lo e poder usá-lo em produção: gerenciamento de dependências e ativos, versionamento de código, uma nova estrutura de projeto, um novo mecanismo de modelo derivado do Laravel, o princípio DRY (Don't Repeat Yourself), e você terá que se ater a padrões de codificação rigorosos que são um pouco diferentes do que WordPress recomenda; mas se você é um desenvolvedor experiente, pode ser uma grande vantagem.

Se você quiser ir all-in com Sage, lembre-se deste conselho de Ben Word, um dos desenvolvedores da equipe Roots:

O Sage não é um framework de temas, é um tema inicial. Você raramente precisa atualizá-lo e, normalmente, não deve criar temas filhos a partir dele. Sendo um tema inicial, o Sage deve ser usado como ponto de partida em um novo projeto.

Mas também:

Se Underscores é um avanço de 1.000 horas, o Sage é um avanço de 10.000 horas.

Estrutura de arquivos e pastas com o Sage

A estrutura de arquivos e pastas do Sage é um pouco diferente do que estamos acostumados a ver em outros temas iniciais, como Underscores, ou mesmo na versão principal anterior do Sage 8.

Isto é o que você encontrará logo após instalar o Sage:

 ├── app/ # it contains all the PHP code of your theme │ ├── controllers/ # your Controllers, it already contains a few │ │ # examples to use as a starting point │ ├── admin.php # setup for the WordPress theme customizer │ ├── filters.php # a good place to group all your theme │ │ # filter hooks │ ├── helpers.php # for various helper functions you want │ │ # to reuse in your theme │ └── setup.php # the main theme setup file ├── config/ # theme configuration files ├── dist/ # all built theme assets, never edit this! ├── resources/ # original theme assets, edit this instead! │ ├── assets/ # all front-end assets │ │ ├── build/ # Webpack and ESLint config │ │ ├── fonts/ # theme fonts │ │ ├── images/ # theme images │ │ ├── scripts/ # theme JS scripts │ │ ├── styles/ # theme SCSS stylesheets │ │ └── config.json # settings for compiled assets │ ├── views/ # all theme Blade templates │ │ ├── layouts/ # base Blade templates │ │ └── partials/ # partial Blade templates │ ├── functions.php # Composer autoloader and theme includes, │ │ # normally you should not edit this unless │ │ # you know what you're doing │ ├── index.php # required by WordPress but left blank │ │ # intentionally, never edit this! │ ├── screenshot.png # the screenshot used in the WordPress admin │ └── style.css # required by WordPress, it should contain │ # only the theme meta information ├── vendor/ # Composer packages, never edit this! ├── composer.json # autoloading for `app/` files ├── composer.lock # Composer lock file, never edit this └── package.json # Node.js dependencies and scripts

Além disso, alguns outros arquivos usados ​​por editores de código e IDEs, como .editorconfig, .eslintrc.js, .stylelintrc.js, phpcs.xml etc.

Aqui está uma rápida visão geral dos requisitos básicos do Sage 9:

• WordPress >= 4,7
• PHP >= 7.1.3 (com php-mbstring habilitado)
• Compositor
• Node.js >= 8.0.0
• Fio

Base rochosa

Bedrock é como o WordPress em esteróides!

Se o Sage melhora o desenvolvimento do seu tema, o Bedrock melhora toda a instalação do WordPress. Ele faz isso fornecendo um padrão de projeto moderno , com uma estrutura de pastas e segurança aprimoradas (por exemplo, não tendo seus arquivos de configuração na raiz do site), arquivos de configuração e ENV e gerenciamento de dependência adequado (sim, incluindo plugins e temas do WordPress) .

Para descrevê-lo em uma única frase, poderíamos dizer que o Bedrock é um projeto WordPress independente que automatiza a instalação de arquivos principais e plugins necessários.

Estrutura de arquivos e pastas

Se você observar uma instalação básica do Bedrock, poderá se sentir perdido no início. O Bedrock separa arquivos da web, configuração e dependência em suas próprias pastas. Aqui está a aparência da estrutura óssea:

 ├── config/ # WordPress configuration files │ ├── environments/ # configuration files for other │ │ │ # environments, they will override │ │ │ # production configuration │ │ ├── development.php # overrides for WP_ENV === 'development' │ │ └── staging.php # overrides for WP_ENV === 'staging' │ └── application.php # main configuration for production │ # environment, it's the equivalent of │ # the wp-config.php file ├── vendor/ # Composer packages, never edit this! ├── web/ # the new root folder of the webserver │ ├── app/ # your new wp-content folder │ ├── wp/ # WordPress core files, never edit this! │ ├── index.php # WordPress view bootstrapper │ └── wp-config.php # required by WordPress, never edit this! ├── .env # all environment variables: db name, │ # user and password, salts, current │ # environment, site urls, and others ├── composer.json # here you can manage versions of │ # WordPress, plugins and other │ # dependencies └── composer.lock # Composer lock file, never edit this

Além de alguns outros arquivos menos importantes.

Os requisitos de base são:

• PHP >= 7.1
• Compositor

Treliça

O Trellis é uma pilha LEMP moderna para gerenciar seus servidores de desenvolvimento, preparação e produção sem problemas, com o objetivo de mantê-los o mais semelhantes possível (“paridade de desenvolvimento e produção”). Isso significa que, se seu site WordPress personalizado funcionar em seu ambiente de desenvolvimento, é seguro assumir que também funcionará em produção e você poderá implantar com confiança.

Para desenvolvimento local, o Trellis faz uso do Vagrant, com um simples vagrant up você terá uma máquina virtual rodando um ambiente moderno e adequado.

O provisionamento e a implantação em seus ambientes de preparo e produção são gerenciados com os playbooks do Ansible, que são arquivos YAML que informam ao Ansible o que fazer.

Estrutura de pastas sugeridas de treliça

O Trellis tem uma estrutura de pastas sugerida composta por apenas duas subpastas:

 ├── trellis/ # the clone of the Trellis repository └── site/ # the Bedrock-based WordPress website

Eu recomendo deixar como está, mas pode ser personalizado dependendo do seu gosto e necessidades.

Requisitos de treliça

• Compositor
• Caixa virtual >= 4.3.10
• Vagante >= 2.1.0

Por que você deve usá-lo

Se o WordPress já está funcionando como está, por que você deveria mudar para uma pilha mais complexa e gastar uma quantidade considerável de tempo para dominá-la? Porque há vantagens óbvias e outras menos óbvias. Vamos tentar ver quais são.

Um tema inicial agnóstico de estrutura

Muitos temas iniciais do WordPress forçam você a usar uma estrutura CSS específica que você pode ou não gostar ou até mesmo conhecer, mas o Sage é completamente agnóstico de estrutura. Durante a instalação, você terá a opção de incluir automaticamente Bootstrap 4, Bulma, Foundation, Tachyons, Tailwind CSS ou nenhum framework se quiser começar do zero ou usar outra coisa (DICA: ultimamente estou começando a gostar do Tailwind CSS muito).

DICA PRO: em uma máquina Windows, você pode receber a mensagem “O modo TTY não é suportado na plataforma Windows” durante a instalação e não poderá escolher uma estrutura ou configurar o Sage. Você terá que executar esses três comandos manualmente de dentro da pasta do tema se quiser aproveitar a configuração automática:

 $ vendor\bin\sage meta # to specify the metadata for your # theme (the name, etc., that goes # in style.css). $ vendor\bin\sage config # to specify your theme's dev URL and # theme directory. $ vendor\bin\sage preset # to set up the theme with one of the # supported frameworks or no # framework at all.

Um processo de construção moderno

Com o Webpack, incluído no Sage, você não terá mais que pensar em compilar ativos, concatenar e reduzir código JavaScript e CSS, otimizar imagens, verificar erros de JavaScript e de estilo e gerenciar bibliotecas externas. O processo de compilação cuidará de tudo isso com um simples yarn build (ou yarn build:production se você quiser que seus assets sejam otimizados para uso em produção), produzindo todos os arquivos estáticos na pasta /dist/ do seu tema.

PHP moderno e requisitos

A versão mínima do PHP na qual você pode executar o WordPress é o PHP 5.2.4, isso garantirá a compatibilidade com versões anteriores para todos os usuários que estão executando seus sites em um ambiente legado, mas as versões antigas do PHP (<= 7.0) atingiram oficialmente o fim de Life, então eles não são mais suportados e podem expor seu site a vulnerabilidades de segurança e problemas de desempenho.

Tanto o Sage quanto o Bedrock requerem uma versão sã do PHP 7.1 (embora, se você tiver a opção de escolher 7.3, faça isso).

O Sage 9 também adota totalmente os padrões de codificação PSR-2 (o padrão de codificação mais amplamente utilizado e aceito

padrões usados ​​na comunidade PHP), que são um pouco diferentes dos padrões de codificação do WordPress, mas permitem que você tenha um código mais limpo e de fácil manutenção, especialmente se você trabalha em equipe ou precisa compartilhar seu código com outras pessoas.

Melhores dependências e gerenciamento de pacotes

A pilha Roots faz grande uso do Composer para gerenciar todas as dependências e pacotes, incluindo o núcleo do WordPress, plugins e temas. Isso pode ser um problema se você usar ferramentas de terceiros para gerenciar atualizações do WordPress (como ManageWP, MainWP ou InfiniteWP), mas alguém pode argumentar que ter tudo sob controle de versão oferece mais controle e facilita a reversão para um trabalho anterior. versão se algo der errado.

Além disso, o Sage usa o Yarn como um gerenciador de pacotes e dependências para o código do aplicativo e para iniciar o processo de compilação.

Arquivos de modelo melhores

O WordPress não possui um mecanismo de modelagem real, então, para compensar, o Sage adotou o Laravel's Blade e segue o princípio DRY: Don't Repeat Yourself.

É assim que o arquivo de modelo single.blade.php padrão se parece, apenas 6 linhas de código:

 @extend('layouts.app') @section('content') @while(have_posts()) @php the_post() @endphp @include('partials.content-single-'.get_post_type()) @endwhile @endsection

O mecanismo de modelo Blade separa completamente Views e Controllers e sua sintaxe é mais elegante, concisa, legível e mais fácil de escrever do que apenas tags PHP. A regra geral aqui é deixar todo o código PHP fora de seus arquivos de modelo (ou pelo menos tentar).

Outro benefício de usar o Blade é a herança de modelos: um modelo de layout básico (o padrão é /resources/views/layouts/app.blade.php ) define blocos contendo os elementos comuns do site, que são então herdados por seus modelos filhos. A herança de modelos é ótima para remover marcações repetidas de modelos individuais e manter as coisas DRY.

Sincronização do navegador

Ao executar o yarn start , você iniciará uma sessão do Browsersync. Browsersync é um módulo para teste de navegador sincronizado durante o desenvolvimento. Ele observará as alterações feitas em seus recursos de front-end e, trabalhando em conjunto com o Webpack, injetará automaticamente as alterações na sessão do navegador.

Implantação rápida, fácil e segura do WordPress

O Trellis oferece implantações WordPress sem tempo de inatividade. Quando você inicia uma implantação, o Trellis clona seu repositório, executa o composer install e, em seguida, atualiza o link simbólico para a versão atual para que nunca edite diretamente os arquivos que estão atualmente em produção.

Ao usar o Bedrock, o Trellis também precisa de muito pouca configuração.

Desvantagens

A única desvantagem de usar a pilha completa de Roots (além de aprender coisas novas, que não devem ser consideradas um problema) é que você precisa usar um provedor de hospedagem compatível com Trellis como Kinsta, um droplet DigitalOcean ou qualquer outro host que suporte pelo menos SSH, Composer e WP-CLI, juntamente com a opção de atualizar o caminho raiz da web.

Isso deixa a maior parte da hospedagem compartilhada barata (ish) fora do jogo e é algo que você e/ou seu cliente devem levar em consideração antes de iniciar um novo projeto.

Como começar

Isso pode ser considerado uma nova versão da famosa “Instalação de 5 minutos do WordPress”, mas para desenvolvedores front-end modernos. Ele adiciona alguns graus de complexidade para desenvolvimento posterior, mas no final, os benefícios que você pode obter definitivamente valem a pena.

Vamos nos concentrar em adotar a pilha completa (Sage, Bedrock e Trellis), mas você pode usar apenas uma ou qualquer combinação delas. O Sage pode ser usado como ponto de partida para um tema autônomo em qualquer instalação do WordPress; O Bedrock pode ser usado com qualquer tema WordPress que você desejar; e as implantações do Trellis são configuradas para sites baseados em Bedrock e cuidam de tudo o que é necessário, mas com um pouco de ajustes, ele pode ser personalizado para praticamente qualquer necessidade.

Como criar um novo projeto

Configurar um novo projeto WordPress com Trellis, Bedrock e Sage é bastante fácil, apenas algumas linhas de comando de distância.

Instale o Trellis na pasta desejada (por exemplo, example.com ):

 $ mkdir example.com && cd example.com $ git clone --depth=1 [email protected]:roots/trellis.git $ rm -rf trellis/.git

Instale o Bedrock na subpasta /site/ :

 $ composer create-project roots/bedrock site $ cd site/web/app/themes/

Instale e construa o Sage:

 $ composer create-project roots/sage your-theme-name $ cd your-theme-name/ $ yarn && yarn build

Implantando

A implantação para teste ou produção é ainda mais fácil se você configurou tudo corretamente de acordo com a documentação oficial. É apenas uma linha de comando de distância (executada da pasta example.com/trellis/ ):

 $ ansible-playbook deploy.yml -e "site=<domain> env=<environment>"

Você também pode reverter facilmente sua implantação, basta executar:

 $ ansible-playbook rollback.yml -e "site=<domain> env=<environment>

Dicas sobre como configurar seu ambiente de desenvolvimento no Windows

Se você pesquisar no Google sobre como instalar e usar a pilha Roots, especialmente Trellis, encontrará muitos tutoriais focados em Linux ou MacOS, mas muito pouca informação está disponível para Windows, onde você encontrará dois problemas principais: Ansible não está disponível para Windows, e o Vagrant geralmente é extremamente lento em máquinas Windows.

Quando eu originalmente pensei sobre este artigo, a documentação oficial do Trellis para Windows estava sugerindo a execução do Ansible dentro da máquina virtual Vagrant, mas essa era uma maneira meio hacky de fazer as coisas e não era muito confiável.

Desde então, eles atualizaram a documentação com as devidas instruções sobre como configurar tudo com o WSL (Windows Subsystem for Linux), então não há necessidade de reinventar a roda e escrever um tutorial sobre isso. É bom saber que existem três páginas de instruções detalhadas passo a passo que você pode seguir antes de instalar o Trellis: Instalação do Windows, Instalação do Windows: Sage e Instalação do Windows: Trellis.

Boa codificação!