Base de conhecimento
Como o zinnector dev executa um WordPress real em sua própria máquina: os dois ambientes de execução (WebAssembly sem Docker ou PHP nativo no Docker), a escolha de uma versão do PHP e do WordPress, o que é servido a partir do seu projeto, onde reside o ambiente de execução de 570 MB e o que acontece no Node 26.
zinnector dev executa um WordPress real em sua própria máquina, servindo os plugins e temas do seu projeto, com a versão do PHP que você escolher. Este artigo explica os dois ambientes de execução (runtimes) que ele pode usar, como escolher versões, o que é servido de onde e onde o runtime fica no disco — para que o que você testa localmente seja exatamente o que você publica.
O Playground é o padrão. O WordPress Playground compila o PHP para WebAssembly e o executa dentro do Node, portanto um laptop sem nada instalado além do Node inicializa um WordPress em segundos. Qualquer PHP de 5.2 a 8.5 está disponível. Ele inclui um pequeno conjunto de extensões PHP (intl, redis, memcached, conforme medido na versão atual), o que é suficiente para a maioria dos trabalhos com plugins e temas.
O Docker executa contêineres nativos de php-fpm e MariaDB. Ele é mais lento, precisa de um daemon do Docker e de cerca de 1,2 GB de imagens, além de oferecer suporte ao PHP 7.4 a 8.5 — mas executa um PHP nativo com o conjunto completo de extensões, incluindo imagick e gd. É a resposta ideal quando o que você precisa testar é uma extensão que a compilação em WebAssembly não possui.
zinnector dev # playground
zinnector dev --runtime docker # PHP nativo + MariaDBNunca há fallback silencioso para o Docker. Um desenvolvedor que pensa estar no WebAssembly e na verdade está no Docker recebeu a resposta errada de uma ferramenta tentando ajudar; por isso, ele precisa ser solicitado explicitamente pelo nome.
zinnector dev --php 8.1 --wp 6.7 # desenvolver para um par específico
zinnector dev --port 9401 # quando a 9400 estiver ocupada
zinnector dev --no-login # não entrar no wp-admin automaticamente
zinnector dev --verbose # exibir a saída do próprio runtimeOs padrões vêm do arquivo zinnector.json no projeto — php, wordpress, runtime e port — o qual é gerado por zinnector new e você deve comitar, para que todos no projeto usem as mesmas versões. Uma flag na linha de comando tem precedência sobre o arquivo para aquela execução.
A versão que você declara e a versão que roda são coisas diferentes. O comando zinnector dev --once inicializa o runtime, imprime o que ele realmente relata — versão do PHP, versão do WordPress, extensões carregadas — e encerra. O comando zinnector check --probe usa a mesma medição ao comparar seu projeto com um slot de hospedagem.
O runtime monta os diretórios wp-content/plugins, wp-content/themes e wp-content/mu-plugins do seu projeto diretamente, de modo que um arquivo salvo fica ativo no próximo recarregamento. Diretórios que existem, mas não contêm conteúdo real, são deliberadamente não montados: uma pasta themes/ vazia montada sobre os temas do próprio runtime deixaria o WordPress sem tema algum, resultando em um erro 500 em branco em vez do seu site. É por isso que o scaffold mantém diretórios vazios com um .gitkeep e por isso eles não ocultam nada até que você coloque um tema neles.
O runtime do WordPress é baixado no primeiro uso em vez de ser fornecido com a CLI — o pacote que contém todas as compilações do PHP tem cerca de 570 MB, e um desenvolvedor que apenas lista sites não deveria ter que baixá-lo. Ele é mantido no próprio cache do Zinnector®, em ~/.cache/zinnector/runtimes/playground/<version> (ou onde quer que ZINNECTOR_CACHE_DIR aponte), nunca dentro do seu projeto, para que não vá parar em seu repositório ou na árvore que zinnector push mede. O download é feito pelo seu próprio npm, executado como node npm-cli.js — nunca por meio de um shell.
A versão do runtime é fixada à versão da CLI, garantindo que dois desenvolvedores em um mesmo projeto usem as mesmas compilações do PHP. O comando zinnector dev --reset-runtime descarta o runtime instalado e o instala novamente, o que resolve o problema de um runtime que foi instalado, mas não inicializa.
A própria CLI roda em qualquer Node a partir da versão 24. No entanto, o módulo nativo do runtime oferece binários pré-compilados apenas para o Node 24 e 25 (em setembro de 2026). Em vez de compilar qualquer coisa — o que no Windows significa instalar o Visual Studio —, o Zinnector® baixa um Node 24 exclusivo para o runtime, com cerca de 30 MB e verificado contra as somas de verificação publicadas pelo nodejs.org, para dentro do mesmo cache. O aviso de instalação informa isso quando for o caso. Nada muda em relação ao seu próprio Node.
O que temos escrito sobre hospedagem, SEO e gerenciamento de sites em grande escala.
Como a hospedagem molda a indexação e o link equity em 2026: mantendo páginas indexadas, avaliando domínios antigos antes de utilizá-los, criando links sem deixar pegadas (footprint) e uma visão honesta sobre o que a infraestrutura pode e não pode fazer pelo SEO.
Ler o artigo →Um checklist prático para um WordPress rápido e seguro: cache no nível do servidor, cache de objetos por site, os poucos plugins que realmente valem a pena, manutenção do stack atualizado e as páginas do WooCommerce que você nunca deve armazenar em cache.
Ler o artigo →O que realmente separa uma boa hospedagem gerenciada de uma máquina barata com painel de controle — migrações, backups, isolamento, cache real e escalabilidade honesta — e como avaliar isso antes de assumir um compromisso.
Ler o artigo →O suporte está incluído em todos os planos, o atendimento funciona 24 horas por dia e você pode nos escrever em qualquer um dos nossos 58 idiomas — nós respondemos no seu.
Entrar em contato com o suporte → Todos os artigos →