O WordPress existe há muito tempo, pelo menos para os 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 por si só, mas este 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 completo de os recursos PHP mais recentes.

Isso também causou muitos Desenvolvedores WordPress viver em um Bolha WordPress , não sendo incentivado a aprender novas e modernas tecnologias de desenvolvimento de front-end e, às vezes, ficar preso na 'boa e velha maneira' de fazer as coisas.

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

Você certamente pode, e o Pilha de raízes do WordPress está aqui para ajudá-lo a se desenvolver como se fosse 2019, com três ferramentas incríveis:

• Sábio como seu tema inicial,
• Base rochosa como um padrão WordPress moderno,
• Treliça para gerenciar a implantação e o provisionamento em diferentes ambientes.

A equipe do Roots também tem duas ferramentas adicionais em desenvolvimento: Bolota , uma estrutura de construção de plug-in e Trevo , um padrão de plugin. Devido ao fato de que ambos estão em alfa, eles não estão incluídos neste artigo, mas você definitivamente deve ficar de olho neles.

Muitas marcas importantes usam Sage e / ou Bedrock em seus sites. Encontre-os no Roots Showcase .

O que exatamente é a pilha de raízes

Originalmente conhecido como o tema Roots, era um tema HTML5 sólido como uma rocha, com o objetivo de fornecer um ponto de partida mais limpo para novos sites WordPress. Com o tempo, ele 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), assim, forçando os desenvolvedores do WordPress que o adotaram a aprender continuamente e se manter atualizados com o que as tecnologias de desenvolvimento front-end modernas têm a oferecer.

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

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

Roots Sage 9

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

O que Sage está tentando fazer é adotar um padrão MVC (Model-View-Controller) em que Views e Controller são completamente separados; isso nos permite reutilizar Visualizações, que não precisam necessariamente 'saber' de onde os dados estão vindo, mas simplesmente aguardam que um controlador os alimente com alguns dados para exibição.

O controlador incluído no Sage 9 não é o controlador real com o qual você já deve estar familiarizado em outros frameworks, como 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ê permite que o WordPress manipule o roteamento de URL e escreva 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 ser capaz de usar na produção: gerenciamento de dependências e ativos, controle de versão de código, uma nova estrutura de projeto, um novo mecanismo de template derivado do Laravel, o princípio DRY (Don't Repeat Yourself), e você terá que seguir padrões de codificação estritos que são um pouco diferentes dos WordPress recomenda; mas se você for um desenvolvedor experiente, pode ser um ótimo ponto de partida.

Se você quiser apostar tudo com Sage, lembre-se deste conselho de Ben Word, um dos desenvolvedores da equipe do Roots:

Sage não é uma estrutura de tema, é um tema inicial. Raramente você precisará atualizá-lo e, normalmente, não deve criar temas filho a partir dele. Sendo um tema inicial, o Sage deve ser usado como um ponto de partida em um novo projeto.

Mas também:

Se Underscores é uma vantagem de 1.000 horas, Sage é uma vantagem 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 Sublinhados , ou mesmo na versão principal anterior do Sage 8.

Isso é o que você encontrará logo após a instalação do 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 visão geral rápida 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 WordPress com 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 projeto moderno clichê , com uma estrutura de pasta aprimorada e segurança (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 plug-ins e temas do WordPress).

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

Estrutura de arquivos e pastas

Se você olhar para uma instalação básica do Bedrock, pode se sentir perdido no início. Bedrock separa os 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 do alicerce são:

• PHP> = 7.1
• Compositor

Treliça

Trellis é um pilha LEMP moderna para gerenciar seus servidores de desenvolvimento, teste e produção perfeitamente, visando mantê-los o mais semelhantes possível entre si (“paridade de desenvolvimento e produção”). Isso significa que, se seu site WordPress personalizado funcionar em seu ambiente de desenvolvimento, é seguro presumir que ele também funcionará em produção e que você pode implantar com confiança.

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

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

Estrutura de pasta sugerida pela Trellis

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 de acordo com o seu gosto e necessidades.

Requisitos de treliça

• Compositor
• Virtualbox> = 4.3.10
• Vagrant> = 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 um tempo considerável para dominá-la? Porque existem vantagens óbvias, e algumas menos óbvias. Vamos tentar ver o que são.

Um tema para iniciantes agnóstico de framework

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

TIPO PRO: em uma máquina Windows, você pode receber a mensagem “O modo TTY não é compatível com a plataforma Windows” durante a instalação e não será possível 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 as vantagens da configuração automática:

$ vendorinsage meta # to specify the metadata for your # theme (the name, etc., that goes # in style.css). $ vendorinsage config # to specify your theme's dev URL and # theme directory. $ vendorinsage 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á que pensar mais em compilar ativos, concatenar e reduzir o código JavaScript e CSS, otimizar imagens, verificar JavaScript e erros de estilo e gerenciar bibliotecas externas. O processo de construção cuidará de tudo isso com um simples yarn build (ou yarn build:production se deseja que seus recursos sejam otimizados para uso em produção), produzindo todos os arquivos estáticos em seu tema /dist/ pasta.

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 versões antigas do PHP (<= 7.0) have officially reached End Of Life, so they are no longer supported and they may expose your site to security vulnerabilities and performance issues.

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

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

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 mais fácil de manter, especialmente se você trabalhar em equipe ou precisar compartilhar seu código com outras pessoas.

Melhor gerenciamento de dependências e pacotes

A pilha Roots faz grande uso do Composer para gerenciar todas as dependências e pacotes, incluindo o núcleo do WordPress, plug-ins 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 dá a você mais controle e torna mais fácil reverter 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 construção.

Melhores arquivos de modelo

O WordPress carece de um mecanismo de modelagem real, então, para compensar, Sage adotou o Laravel's Blade e segue o princípio DRY: Não se repita.

Esta é a aparência do arquivo de modelo single.blade.php padrão, 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 template Blade separa completamente Views e Controllers e sua sintaxe é mais elegante, concisa, legível e fácil de escrever do que apenas tags PHP. A regra 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 do template: um template de layout base (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 templates filhos. A herança de modelos é ótima para remover marcações repetidas de modelos individuais e manter as coisas SECAS.

Browsersync

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

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

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

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

Inconvenientes

A única desvantagem de usar a pilha completa do Roots (além de aprender coisas novas, o que não deve ser considerado um problema) é que você tem que 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, junto com a opção de atualizar o caminho da raiz da web.

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

Como começar

Isso pode ser considerado uma nova abordagem da famosa “Instalação do WordPress 5-Minute”, mas para desenvolvedores de front-end modernos. Isso 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; Bedrock pode ser usado com qualquer tema WordPress de sua preferência; 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, pode ser personalizado para quase 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 a base rochosa em /site/ subpasta:

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

Instale e crie 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 (executado a partir da pasta example.com/trellis/):

$ ansible-playbook deploy.yml -e 'site= env='

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

$ ansible-playbook rollback.yml -e 'site= env=

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, você 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 pensei originalmente neste artigo, a documentação oficial do Trellis para Windows sugeria que o Ansible fosse executado 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 instruções adequadas sobre como configurar tudo com 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: configuração do Windows , Configuração do Windows: Sage e Configuração do Windows: Trellis .

Boa codificação!

Relacionado: Como abordar o desenvolvimento WordPress moderno (Parte 1, o front end) e Parte 2 (back end)

Compreender o básico

Qual é a pilha de raízes?

A pilha Roots é um conjunto de ferramentas destinadas a ajudar os desenvolvedores a criar sites WordPress melhores, adotando tecnologias modernas e acompanhando todo o ciclo do desenvolvimento à preparação e à produção.

Como faço para criar um ambiente de desenvolvimento WordPress?

Criar um ambiente de desenvolvimento WordPress com Trellis é tão fácil quanto digitar alguns comandos na janela do seu terminal. A Trellis, com a ajuda do Vagrant, cuidará de configurar uma pilha LEMP adequada em uma máquina virtual para você. Algumas etapas adicionais podem ser necessárias se você estiver em uma máquina Windows.

O que é um desenvolvedor WordPress full stack?

Um desenvolvedor WordPress full stack deve ser capaz de configurar e gerenciar uma infraestrutura de servidor LAMP / LEMP e trabalhar tanto no front-end, criando um tema, quanto no back-end, codificando novos recursos na forma de plug-ins. Ele deve ter um bom conhecimento de PHP, SQL, JavaScript, HTML e CSS.