Pressione isto: WPGraphQL e Faust.js

Bem-vindo ao Press This, o podcast da comunidade WordPress da WMR. Cada episódio apresenta convidados de toda a comunidade e discussões sobre os maiores problemas enfrentados pelos desenvolvedores do WordPress. O que se segue é uma transcrição da gravação original.

Desenvolvido por RedCircle

Doc Pop : Você está ouvindo Press This, um podcast da comunidade WordPress no WMR. A cada semana, destacamos os membros da comunidade WordPress. Sou seu anfitrião, Doc Pop. Apoio a comunidade WordPress por meio de minha função no WP Engine e minhas contribuições no TorqueMag.Io, onde faço podcasts e desenho cartoons e vídeos tutoriais. Dê uma olhada.

Você pode se inscrever no Press This no Red Circle, iTunes, Spotify ou baixar episódios diretamente em wmr.fm.

Neste episódio do Press This, falamos sobre Headless WordPress, GraphQL e Faust.js. Como essas ferramentas podem ser usadas juntas e que tipo de custo pode ser associado ao Headless WordPress. Vamos tentar mergulhar fundo nisso, e tenho dois grandes convidados se juntando a mim hoje, tenho Jason Bahl, um engenheiro de software principal da WP Engine com sede em Denver, Colorado, onde ele mantém o WPGraphQL . E temos Chris Weigman, um gerente de engenharia trabalhando no Faust.js. Normalmente, gosto de começar esses programas perguntando aos convidados sobre suas histórias de origem do WordPress, mas pensei em mudar um pouco as coisas aqui.

Jason, você pode nos dizer o que é WPgraphQL e qual é a história da origem do wordPress.

Jason Bahl: Sim, o WPGraphQL é um plug-in WordPress de código aberto gratuito que traz uma API GraphQL para o seu site WordPress e o GraphQL é uma linguagem de consulta gráfica. Portanto, permite que os desenvolvedores obtenham conteúdo dentro e fora do WordPress usando a linguagem de consulta gráfica.

E o plugin se originou, eu trabalhava em um jornal há alguns anos e fazíamos muita distribuição de conteúdo. Tínhamos uma rede de cerca de 54 sites em todos os Estados Unidos e precisávamos mover o conteúdo de um lado para o outro. Você sabe, quando uma notícia era publicada, diferentes jornais podiam assinar o conteúdo de outros jornais.

E assim, quando vários eventos ocorreram, precisávamos mover dados por essa rede e estávamos usando a API REST do WordPress para fazer grande parte dessa movimentação de dados. E estamos tendo alguns problemas com isso tecnicamente e como o desempenho real tecnicamente, mas também a experiência do desenvolvedor. Eu descobri sobre o GraphQL, a linguagem de consulta gráfica real, cujo código foi aberto pelo Facebook em 2015.

Então eu encontrei essa tecnologia, fiz alguns protótipos, apresentei para meus colegas e então migramos nossa distribuição de contatos de REST para GraphQL. E então continuei trabalhando no projeto como um projeto de comunidade sabendo que as estruturas JavaScript estavam se tornando a coisa quente e que provavelmente seria o principal caso de uso do GraphQL, como a comunicação de servidor para servidor não é o principal caso de uso. Ele resolveu nossas necessidades, mas vi uma visão maior para isso, então continuei trabalhando nele como um projeto de código aberto para a comunidade.

DP: Bem, legal. Chris, você pode nos contar uma história semelhante sobre o que é Fausto e como ele surgiu?

Chris Weigman: Claro que o Faust foi, recentemente, nesta semana, oficialmente lançado ao público, relançado para a estrutura pública para a construção de sites Headless WordPress usando GraphQL. Bem, o desenvolvimento começou em 2020, e era uma espécie de projeto não oficial do WP Engine, e este é o terceiro grande pivô.

Eles começaram como uma extensão do DevRel, meio que começaram a torná-lo um pouco mais oficial e giraram em algo chamado GQty e uma mentalidade de desenvolvedor muito JavaScript. E então, quando assumi a equipe em 1º de dezembro do ano passado, percebemos que aquele não era nosso mercado-alvo.

Deveríamos estar desenvolvendo para desenvolvedores WordPress. Então começamos a reconstruí-lo novamente, e ele finalmente pôde ser relançado recentemente.

DP: Jason, você twittou recentemente que lançou o novo wpgraphql.com no Faust.js. O site anterior, acredito, era um WordPress sem cabeça. Você pode nos contar sobre essa mudança que você fez e quais melhorias você está dizendo?

JB: Sim. Então wpgraphql.com, tem sido um site headless por muitos anos. Então, estou usando várias fontes de dados. Portanto, tenho muito conteúdo no WordPress, como as postagens do blog, todas no WordPress.

Parte da documentação também existe no WordPress. E existe alguma documentação em arquivos markdown no repositório GitHub. Por muito tempo eu estava usando o Gatsby, talvez por uns três anos, eu estava usando o Gatsby, que é uma estrutura JavaScript que em seu núcleo tem sua camada de dados onde você pode extrair dados de várias fontes.

Então, eu estava usando isso, ele puxava dados do GitHub, puxava dados do WordPress usando WPGraphQL também e me permitia usar esses dados para construir meus modelos. Então, eu estava usando isso por alguns anos. Há muitos pontos problemáticos com a camada de dados que eu queria eliminar.

Então, eu queria usar o Next, que é o que Faust é construído. É outra estrutura JavaScript, mas havia muitas peças faltando, eu acho. Em seguida, muitos desses frameworks JavaScript têm a ideia de que seus frameworks front-end devem definir todo o roteamento, certo? Mas se você estiver usando um CMS, seu CMS definirá o roteamento.

E há muitos problemas técnicos para fazer essas coisas funcionarem bem, onde seu front-end tem uma opinião sobre algo e seu back-end tem uma opinião diferente. Então, um dos problemas que eu estava tentando resolver é fazer meu front-end reconhecer que um URL específico era um tipo específico de coisa e, em seguida, renderizar um modelo que representasse essa coisa.

Como uma postagem de blog tem um modelo diferente de um documento ou arquivo de usuário ou qualquer outra coisa. Então, eu queria que meu front-end tivesse a capacidade de enviar uma URL para o CMS, obter dados de volta, mas entender qual modelo retornar. No WordPress é chamado de hierarquia de templates. E então, quando a equipe do Faust conseguiu resolver esse problema, eu pensei, sim, estou mudando para o Faust.

Então, sim, eu posso pegar alguns dos conceitos que existem no núcleo do WordPress, como temas PHP e usá-los sem comando para que eu possa usar os benefícios do React e qualquer JavaScript que eu queira usar no front-end para modelar meu site, mas ainda conceitos familiares do mundo WordPress.

DP: Chris, você estava mencionando que Faust meio que passou por algumas mudanças. Quais foram essas mudanças? Você sabe, Jason estava mencionando-os. Quais foram algumas dessas mudanças que tornaram essa melhoria possível?

CW: É sempre focado no WPGraphQL. Era todo o resto que era realmente o problema. Por exemplo, a última versão principal do Faust usava uma biblioteca abaixo para interagir com o GraphQL chamada GQty, que no papel parecia muito legal. A ideia da equipe do Faust na época era que, vamos apenas abstrair, as pessoas não precisassem saber como construir essas consultas complexas.

Esta estrutura deve abstrair isso para você. No papel parecia muito bom, na prática por causa de todas as complexidades dos dados do WordPress. Mesmo um único tipo de postagem pode ter tantas variações. Talvez você esteja misturando isso com categoria, talvez todas as coisas diferentes. GQty simplesmente não conseguiu.

Além disso, quando foi construído com a versão GQty, realmente não houve atenção ao problema de roteamento do qual Jason falou. Quem cuida do roteamento? O WordPress quer lidar com seu roteamento de acordo com o conteúdo, é um sistema de gerenciamento de conteúdo, portanto, todo o roteamento e o WordPress são amplamente baseados em conteúdo.

Next.js é uma estrutura de front-end, portanto, todo o roteamento é baseado em um paradigma completamente diferente de como o roteamento é baseado. O que poderia ser /Blog no Next pode não ter nada a ver com o conteúdo de um blog. Está indo para um conjunto de modelos. Vai para parte do aplicativo que pode construir um blog.

Considerando que /Blog no WordPress pode muito bem significar, essas são todas as postagens do blog. E esse paradigma ao construir, se você deseja tornar o WordPress um front-end muito sólido ou um CMS sem cabeça, tivemos que lidar com esse roteamento. Outra mudança quando fizemos isso, como eu disse com a versão GQty, nosso objetivo eram desenvolvedores de JavaScript que precisavam usar o WordPress, o que parece nobre até você perceber que é o WP Engine.

Estamos lidando com agências que construíram no WordPress por anos, que agora, por vários motivos que podemos abordar mais tarde, estão se movendo para uma coisa sem cabeça. Eles sabem como fazer o desenvolvimento do WordPress. Eles entendem como os roteamentos de modelos do WordPress funcionam e os modelos funcionam, coisas assim.

Precisamos trazer esses recursos adiante, para que o GraphQL possa ser usado com mais facilidade pelos desenvolvedores do WordPress. E é esse o objetivo de Faust aqui. A hierarquia de modelos simplesmente reconstrói o que o WordPress fez. Agora, se você quiser usar o roteamento do Next, existem maneiras de substituí-lo no aplicativo para não perder nada.

Mas para as pessoas que estão usando o WordPress como um verdadeiro sistema de gerenciamento de conteúdo, capaz de rotear conteúdo pelo gerenciamento de conteúdo, o Faust vai lidar com isso muito melhor para você? Isso faz sentido?

DP : Sim. Absolutamente. Sabe, acho que é um bom lugar para fazer uma pausa rápida aqui. Você está ouvindo o Press This, um podcast da Comunidade WordPress com Chris Weigman e Jason Bahl. Voltaremos para falar sobre WordPress e headless. Fique atento.

DP: Estamos de volta com Press This. E você sabe, Chris, logo antes daquele intervalo, você mencionou algo, você mencionou mais e mais empresas entrando sem cabeça, e eu sei que o WP Engine fez muitas pesquisas para mostrar que esse é o caso. Estou meio que me perguntando, sem cabeça definitivamente tem uma reputação como algo, acho que empresa, quando penso sem cabeça, estou pensando corretamente. É isso que é sem cabeça? É apenas uma ferramenta para empresas ou é uma ferramenta que mais sites usarão?

CW: Sim e não. Em grande parte sem cabeça, especialmente com o WordPress no momento, a complexidade envolvida significa que você provavelmente tem uma equipe completa desenvolvendo o que precisa.

Não se trata de alguém apenas usando o WordPress pronto para uso, que você deseja apenas ter seu blog pessoal. Ele pode fazer isso, mas é um levantamento muito mais pesado até agora para ser capaz de fazer isso. O mesmo com o Contentful, o mesmo com todos esses outros CMSs. Se você quer apenas algo simples, algo que, você sabe, o tipo de conteúdo que está na web há anos, headless é provavelmente mais trabalhoso do que você gostaria de lidar até agora.

É estritamente empresarial? Olha, não. Gatsby está trabalhando neste problema há anos. Você tem outro podcast mais tarde, Doc with Mastodon. É uma comunidade com a qual estou envolvido há vários anos. A maioria das pessoas está usando variações de CMSs sem cabeça, especialmente Gatsby, mas há Hugo. Há todos os tipos de diferentes, esse tipo de tecnologia em um nível muito popular.

Então você acaba com os usuários de base e acaba com os usuários corporativos para sites pesados, enquanto o WordPress tradicionalmente parece cair com todos os outros no meio. É a pessoa que não quer lidar com arquivos markdown e códigos como um usuário do Gatsby faria, ou você sabe, apenas o Gatsby pronto para uso.

Mas também não é alguém que tem uma equipe inteira de 10 pessoas construindo sua marca pessoal ou blog pessoal. Isso tira o WordPress desse meio e o expande para ambas as extremidades com muita facilidade. Agora você pode criar facilmente entre o GraphQL, você tem todos os dados e um conjunto cada vez maior de maneiras de lidar com esses dados.

E o Faust torna muito mais fácil utilizar isso e algo que você pode construir em um dia em vez de um mês.

DP: Jason, Chris mencionou algo sobre o qual gostaria de ouvir sua opinião, ouvi dizer que talvez isso não seja ótimo para equipes pequenas, pequenos blogueiros como eu, o que obviamente faz sentido, não preciso de um WordPress sem cabeça, mas como , Acho que o que estou pensando é: o WordPress sem cabeça vai me custar mais porque vou ter que ter um desenvolvedor iOS e um desenvolvedor WordPress? É mais caro ou é de alguma forma mais econômico?

JB: Provavelmente depende do que você está produzindo, eu acho. Se você está fazendo, como mencionou o iOS, se está fazendo um aplicativo móvel nativo, obviamente há custos associados a isso, e não há realmente uma boa maneira de fazer isso se você estiver usando dados do WordPress, outros do que fazer sem cabeça, porque você sabe, um aplicativo nativo não renderiza php, então você teria que fazer isso sem cabeça.

Mas se você está construindo para a web agora no WordPress tradicional, você pode encontrar um tema, você conhece um tema gratuito ou encontra um tema em um mercado, baixe-o, instale-o e você está partir para as corridas. A maioria das pessoas vai personalizá-lo de uma forma ou de outra.

Então você terá o custo do desenvolvedor normalmente, seja você mesmo fazendo isso ou outra pessoa. Uma das coisas com o WordPress headless que difere dos temas PHP tradicionais é que, por exemplo, quando lancei o novo wpgraphql.com, pude usar a mesma instância do WordPress que alimentava meu site Gatsby.

Estou obtendo os dados, os dados estavam saindo e indo para o site Gatsby, pude continuar publicando conteúdo no CMS enquanto desenvolvia meu próximo front-end para ele ao mesmo tempo. No desenvolvimento tradicional do WordPress, você geralmente precisa migrar seu site para um ambiente de teste.

Ative um novo tema nesse ambiente, crie seu tema lá, lide com algum tipo de período de congelamento de conteúdo em que você diz aos criadores de conteúdo: “Ei, hoje você não pode publicar conteúdo porque vamos migrar e depois vamos definir a nova instância do WordPress, a instância ativa.” E então você tem que fazer login lá e começar a fazer o seu conteúdo direito.

Headless WordPress, consegui reconstruir meu site em uma pilha de front-end completamente diferente sem interromper nada em minha instância real do WordPress, é uma separação de dados e apresentação, certo? Então eu poderia ir, se quisesse explorar a próxima tecnologia quente amanhã, como se pudesse colocar minha visão no Svelte em vez do Next, e não teria que mudar nada no WordPress.

Então, em alguns casos, pode ser mais barato porque todo esse processo de ativar outro servidor, fazer com que sua equipe pare de escrever conteúdo e, em seguida, mude para uma instância diferente do WordPress e comece a publicar lá, fazendo migrações Delta, coisas assim, isso tem um custo também.

Outra coisa que também é interessante é que o ecossistema JavaScript está realmente sendo enviado. O impulso comum, na minha opinião, um dos motivadores comuns para mover sem cabeça são as arquiteturas baseadas em componentes. E há todos os tipos de bibliotecas de componentes no ecossistema React e VUE, que permitem reutilizar componentes em projetos.

E assim as agências podem construir componentes comuns que usam em projetos e podem atualizá-los em um local central, mas depois instalá-los em vários projetos. Com o WordPress, isso não é tão fácil, porque as partes do modelo PHP e o WordPress geralmente estão muito ligados ao projeto ao qual pertencem.

Onde com headless você pode ter um pacote MPM que possui esses componentes e vários projetos podem atualizar esse pacote e se beneficiar ao mesmo tempo com menos esforço. Então, acho que no momento, eu diria que provavelmente é mais caro e mais trabalhoso, mas acho que ferramentas como Faust, que não existiam até recentemente, estão diminuindo o esforço geral necessário para construir sem cabeça.

E acho que em um futuro não muito distante, pode ser mais barato construir sem cabeça do que sem cabeça.

DP: Chris, você tem algo que gostaria de acrescentar ao que as agências podem precisar considerar em termos de custos do WordPress headless?

CW: Eu acho que Jason realmente acertou em cheio.

E uma coisa que eu gosto no WPGraphQL é que minha equipe está trabalhando para estender o WordPress nessa direção com o que chamamos, nosso título de trabalho é React Gutenberg Bridge, mas também é um problema no WordPress. Como você reutiliza esses componentes? Não quero usar a palavra apenas componente, porque ela não se aplica ao lado do WordPress da mesma forma que se aplica ao lado do JavaScript, certo?

Mas como reutilizamos o código entre projetos, headless ou não com o WordPress e headless permite isso. Mas acho que é seguro dizer que o blogueiro médio apenas tentando divulgar seus blogs gastronômicos, provavelmente não está lidando com isso sozinho. Isso é um problema de agência. Isso é mais custo?

Talvez sim, talvez não, mas é aí que fica complicado quando falamos onde está o custo nisso? Porque são diferentes tipos de como você deseja usar os dados.

DP: Sim, com certeza. Você sabe, vindo de um jornal, trabalhando em Weeklys nas cidades gêmeas e em Nashville, Jason, posso imaginar como seria dizer a seus 56 jornais para não publicar por um dia.

Sem novidades hoje, pois estamos atualizando o site.

JB: Sim. E quero dizer, nós passamos por esses períodos, certo? Como quando fui contratado lá, eles não estavam no WordPress e, portanto, parte do meu trabalho era levá-los de outro sistema para o WordPress. Definitivamente, havia dias em que era como, tudo bem, é o dia do WordPress. Pare o que está fazendo. Direita.

Definitivamente, houve períodos como esse ou também tivemos que lidar com essa questão de, ok, eles estavam publicando no sistema antigo até a meia-noite de ontem, mas tínhamos o WordPress pronto para funcionar dois dias antes disso. Portanto, agora temos que fazer uma migração Delta e garantir que todos os dados ainda estejam sincronizados para que haja definitivamente custos técnicos e humanos para esses processos, com certeza.

DP: Sim. E também acho que há muito, quando você ainda está usando o WordPress, você ainda obtém esse ecossistema que pode obter essa economia de custos. Você não precisa construir as ferramentas de SEO.

Você pode usar o plugin Yoast SEO ou qualquer outro. Mesmo que você seja um site sem cabeça, presumo que a maioria dos plug-ins ainda funcionará, desde que não sejam frontais.

JB: Sim. Isso é realmente uma coisa interessante. Assim, o novo Faust é construído com uma arquitetura de plugins própria. Assim como fora da caixa, ele virá com um cliente, está usando o cliente Apollo para que você possa buscar dados do WPGraphQL, você pode obter seus dados do WordPress, mas você pode criar plugins para que, digamos que você fez, como você mencionado, instale Yoast SEO em seu site WordPress.

Você pode adicionar um plugin Yoast. Ainda não existe, mas em breve poderá. Você poderia adicionar um plugin Yoast para Faust no frontend que sabe o que fazer com esses dados, certo? Portanto, haverá capacidade para as pessoas, algumas que podemos produzir e oferecer suporte, mas algumas, a comunidade pode produzir e oferecer suporte a plug-ins para o lado Faust das coisas também, para que você, com apenas uma linha de código, adicione este plug-in obtenha funcionalidades como o Yoast para o seu front-end sem cabeça.

É algo que eu não acho que qualquer outro frontend sem cabeça realmente tenha o conceito da mesma forma que Faust está abordando. Acho que o plug-in é outra coisa familiar para os desenvolvedores do WordPress. Ele está trazendo conceitos familiares do WordPress, mas fazendo a ponte com a pilha de front-end JavaScript moderna.

DP: esse é um bom lugar para uma pausa final aqui no Press This, e quando voltarmos, encerraremos nossa conversa com Chris Weigman e Jason Bahl. Fique atento.

DP: Você está ouvindo Press This, um podcast da Comunidade WordPress. Sou seu anfitrião, Doc Pop. Hoje estamos falando sobre WPGraphQL, Faust e como você pode potencializar seu site WordPress headless. Logo antes do intervalo, estávamos conversando sobre Faust e plugins e vou apenas lançar algumas perguntas aleatórias para vocês e apenas ver se há alguma boa resposta aqui que apareça.

Mas Chris, estou me perguntando com, com Faust, existe algum potencial, eu sei que é uma plataforma sem cabeça, mas existe algum potencial para um tema WordPress Faust que pelo menos permite que você configure como, aqui estão os plugins que você precisa e aqui está tudo pronto para uso.

CW: Com certeza. Na verdade, já temos. Estamos nos referindo a ele como Blueprints porque funciona muito bem com o Local. A maioria das pessoas fará algum tipo de ajuste antes de lançá-lo em uma plataforma como o WP Engine. Então pegamos emprestado o nome de Blueprints da Local.

Para o novo Faust, temos um chamado Portfolio, que é basicamente um tema de portfólio completo e estamos trabalhando apenas em um andaime em branco que as agências podem usar. Depois de pegar o jeito das coisas, você provavelmente vai querer customizar tudo sozinho. Portanto, um andaime seria as melhores práticas do projeto, gire-o e você poderá fazer todas as suas próprias coisas com ele.

Há muito tempo falamos muito sobre uma loja temática sem cabeça, ala Blueprints. Não temos mão de obra, então isso está um pouco distante, mas é absolutamente algo que estamos, estamos considerando e gostaríamos de ver acontecer.

DP: Sim, é legal pensar nisso. Esse é um tipo totalmente diferente de ecossistema para entrar.

E você sabe, Jason, eu já entrevistei você antes, e tenho certeza que essa pergunta surge o tempo todo, mas toda vez que ouço sobre o WPGraphQL, penso que isso se parece muito com o que a API REST faz. Na verdade, isso parece muito mais poderoso do que a API REST faz e a API REST faz parte do núcleo e estou apenas me perguntando, você acha que o WPGraphQL deveria fazer parte do WordPress Core?

JB: Talvez um dia. Acho que ainda não chegamos lá. Quando as coisas são mescladas no WordPress Core, provavelmente com exceção de Gutenberg, a inovação é interrompida. A API REST, por exemplo, ainda há um bug que aponto para as pessoas que ainda existe, acho que de 2016. Então, quero dizer, quando as coisas vão para o núcleo, você está adicionando um recurso definido para 40 ish por cento da web e portanto, fazer alterações deve ser feito em um ritmo muito mais lento, onde, se for um plug-in, você pode permitir que as pessoas optem pela versão que desejam e você pode iterar muito mais rápido porque eles podem escolher qual versão funciona melhor para seu projeto.

Onde no núcleo, se você atualizar o núcleo e incluir alterações de quebra, você pode ter quebrado 40 por cento da web. Portanto, o GraphQL é uma especificação, não tem nada a ver com o WordPress também.

Direita. E assim a especificação GraphQL ainda está evoluindo. E, à medida que isso continua a evoluir, queremos acompanhar as melhores e mais recentes especificações do GraphQL. Se fundíssemos, digamos, o WPGraphQL no Core hoje, e o GraphQL continuasse evoluindo, o WordPress ficaria preso na edição 2022 do GraphQL, onde o resto do mundo está na versão 2030 ou qualquer outra. Para mim, acho que pode fazer sentido em algum momento reconhecê-lo como WPCLI como a maneira oficial de fazer a coisa X.

Como se você pudesse criar seu próprio cliente CLI para WordPress, mas é meio que reconhecido pela comunidade que o WPCLI é a coisa oficial. Não faz parte do WordPress Core, mas é reconhecido pela WordPress Foundation e pela maior parte da comunidade WordPress como algo oficial. Portanto, pode ser bom em algum momento para um WPGraphQL ser reconhecido assim, como se você for fazer um WordPress sem cabeça, faça desta maneira.

Ainda vai continuar sendo um plugin. Esse é o meu pensamento. Pode haver um momento em que o GraphQL pareça perfeito e não esteja realmente sendo iterado e talvez nesse momento consideremos isso. Mas, neste momento, há coisas chegando à especificação do GraphQL que farão com que a API tenha alterações importantes.

Portanto, fazer isso como um plugin para mim ainda faz sentido.

DP: Certo. E sim, você mencionou o WPCLI e continuo esquecendo, como se eles apenas sentissem que faz parte do núcleo. O que quer que pareça, é oficial. Então, sim, é como se fosse uma coisa independente, assim como o WPGraphQL é no momento.

Essa é uma boa analogia. Então eu vou, eu vou encerrar aqui. Tem sido muito bom conversar com vocês dois. Se os ouvintes estiverem interessados ​​em seguir algum de vocês, podem seguir @JasonBahl e @ChrisWeigman. Colocaremos os identificadores do Twitter na descrição do programa, se pudermos. Você está ouvindo o Press This, um podcast da Comunidade WordPress no WMR.

No episódio da próxima semana, teremos Anne McCarthy, uma representante de produtos da Automatic, falando sobre mudanças na edição do site e 6.1 e o que está por vir com o 6.2. Obrigado novamente por ouvir Press This.

Você pode acompanhar minhas aventuras com a revista Torque no Twitter @thetorquemag ou pode acessar torquemag.io, onde contribuímos com tutoriais, vídeos e entrevistas como esta todos os dias. Então confira torquemag.io ou siga-nos no Twitter. Você pode se inscrever no Press This no Red Circle, iTunes, Spotify ou baixá-lo diretamente em wmr.fm toda semana. Sou seu anfitrião, Doutor Popular. Apoio a comunidade WordPress por meio de minha função na WP Engine. E adoro destacar os membros da comunidade todas as semanas no Press This.